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ABSTRACT 



Electronic data interchange (EDI) is the intercompany, computer-to- 
computer exchange of business documents in standard formats. The di- 
rect benefits of EDI consist in cost savings, operational accuracy, and 
speedy processing of transactions. This thesis provides guidelines to de- 
velop an EDI (Electronic Data Interchange) system. It discusses the basic 
concepts, standards, data mappping, hardware and software requirements, 
and networking requirements. Also discussed are some auditing and se- 
curity issues in implementing EDI. 



I^/o 

j,/ 

TABLE OF CONTENTS 

I. INTRODUCTION I 

II. EDI DEVELOPMENT AND STANDARDS 4 

A. OVERVIEW 4 

B. ANSI XI2 STANDARDS 6 

1. Organization of ANSI ASC X12 6 

2. Description of ANSI XI 2 standards II 

C. EDIFACT 17 

D. CALS 20 

Background 20 

2. What is CALS? 22 

3. Relationship between EDI and CALS 24 

III. ANALYSIS OF TRANSACTION AND DATA MAPPING . 26 

A. TRANSACTION AND DATA FLOW 26 

B. DATA MAPPING ; . . 33 

1. The paper system 35 

2. Integrating with the existing database 36 

3. Integrating with existing applications/processes 38 

4. Developing new applications/processes based on EDI ... 39 

5. Fully integrated application/EDI system development ... 41 

IV. HARDWARE AND SOFTWARE REQUIREMENTS 43 

A. HARDWARE REQUIREMENTS 43 



IV 



B. SOFTWARE REQUIREMENTS 



45 



V. NETWORKING REQUIREMENTS 51 

A. TELECOMMUNICATIONS INFRASTRUCTURE 51 

1. COMMUNICATIONS STRUCTURE 51 

a. Integrated-Internal network structure 53 

b. Integrated-External network structure 54 

c. Partitioned-Internal network structure 54 

d. Partitional-External network structure 55 

2. PROTOCOLS 55 

a. 3780 and 2780 55 

b. 3270 and 3770 56 

c. VTIOO, TTY and C03 56 

d. X.25 57 

3. NETWORKS 57 

a. Separating the functions 58 

b. Network management 58 

c. Public & Private network 59 

B. USE OF THIRD PARTY NETWORKS 60 

VI. AUDITING AND SECURITY ISSUE 65 

A. AUDITING 65 

B. SECURITY 67 

VII. CONCLUSION 71 

LIST OF REFERENCES 74 



V 



INITIAL DISTRIBUTION LIST 



76 



VI 



ACKNOWLEDGEMENTS 



I would like to thank the Korean Army for the opportunity to study at 
the Naval Postgraduate School. I wish to thank to Dr. Myung W. Suh 
for his patient guidance, continuous assistance and very helpful criticism 
throughout this work. I am very grateful to Dr. Dan C. Boger whose 
comments and recommendations contributed to the successful completion 
of this thesis. Finally, I am also grateful to my wife, Myung Hwea, and 
daughter, Gi Hea, for their support and patience in my country. 



I. INTRODUCTION 



Electronic data interchange (EDI) is the intercompany, computer-to- 
computer exchange of business documents in standard formats. Through 
EDI, such common business forms as invoices, bills of lading, and pur- 
chase orders are transformed to a standard data format and electronically 
transferred between trading partners. 

Electronic Data Interchange (EDI) is fast becoming the standard way 
of exchangeing business documents, not only in this country but also in 
the rest of the world. EDI provides a faster, more accurate, less costly 
method of communication than do traditional methods of business com- 
munications such as mail, telephone, and personal delivery. However, 
EDI is doing more than just changing how businesses communicate; it is 
changing the way businesses operate. Electronic data interchange is 
changing industry. Trading relationships are changing, management 
philosophes are changing, and production techniques are changing. 

The direct benefits of EDI are immediately apparent from its defi- 
nition; 

• Saving: EDI eliminates paper, postage premiums for overnight de- 
livery, and the like. Rooms full of data entry personnel and equip- 
ment become obsolete. 
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• Accuracy: EDI communication is direct, instantaneous, and imme- 
diately verifiable. That means no more lost or misrouted mail. 
Documents exchanged are 100 percent accurate and complete. This 
make such jobs as reconciliation for payment much easier. All this 
provides additional savings. 

• Speed: Instantaneous communication is an important EDI benefit 

to those companies that compete on cycle time. EDI is essential in 
supporting just-in-time(JIT) delivery schedules. 



The costs and benefits of incorporating EDI into a business operation 
have been estimated by Price VVaterhous as follows: For a typical $10 
million company, the annual cost EDI costs will remain fairly steady be- 
tween 10 and 12 million dollars per year. However, the annual saving for 
the company will increase each year yielding a total saving over the fi\e 
year period of $200 million [Ref. 1; p. 27]. 

In the U.S., there are currently about 5,000 companies using EDI, and 
that number is expected to double annually for the next three years. Al- 
ready in the automotive, chemical, pharmaceutical, and grocery indus- 
tries, EDI has become a prerequisite for doing business -- that is, 
companies not currently EDI - capable are suffering a competitive dis- 
advantage. Several other industries -- railroads, apparel, textile, retail, 
electronics, health care -- are not far from this level of EDI commitment. 
Growth of EDI in other industries will be rapid, as companies seek to 
leverage their EDI investments over all their trading partners. By 1993, 
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an estimated 70 percent of U.S. businesses will make significant use of 
EDI [Ref. 2: p. 11]. 

EDI use is spreading internationally, as well. Virtually nonexistent as 
little as two years ago, the international EDI market is blossoming- 
particularly in Great Britain and Canada. There are now 900 major 
European companies using EDI and that number is expected to grow to 
140,000 by 1995. Just as it would be almost unthinkable nowadays for a 
business not to have a telephone to communicate with customers and 
suppliers, it may be almost as unthinkable for a business not to have a 
computer for the same purpose. 
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II. EDI DEVELOPMENT AND STANDARDS 



A. OVERVIEW 

Standards are fundamental to EDI. EDI is the intercorporate ex- 
change of business documentation in structured, rnachine-processable 
form. EDI is designed so that the receiving computer can read and proc- 
ess data without additional human intervention. This means that the data 
must be in coded rather than te.xtual format. EDI standards provide a 
widely accepted format to convey the meaning of the exchanged data. 
They allow the sender to encode data in the same format for many re- 
ceivers, and require the receiver to maintain only one piece of software 
to decode data received from many senders. Standards for EDI have been 
established and maintained by several organizations for a \,iriety of 
business functions. EDI format standards are ’’'tended to enhance EDI 
transactions across industry lines and to foster a common language for 
cross-industry EDI system. 

The first attempt to develop standards occurred in the late sixties in 
the transportation industry. In 1968, a group of companies in the trans- 
portation industry joined together and formed the Transportation Data 
Coordinating Committe (TDCC). The committee published its first 
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standards in 1975 and has since developed and published standards used 
primarily in the air, motor, rail, and ocean carriers. Other industries fol- 
lowed the TDCC's lead and developed EDI standards for their own in- 
dustries, most notably the grocery and the warehousing industries. The 
standards for the grocery industry are termed Uniform Communication 
Standards while the standards for the warehouse industry are termed 
Warehouse Information Network standard (WINS) [Ref. 3: p. 64]. 

In 1978, the American National Standards Institute (ANSI) recog- 
nized the need for national EDI standards that could be used across in- 
dustries. ANSI is coordinr,tor and clearing house for national and 
international standards whose membership represents nearly all technical 
disciplines and all areas of trade and commerce. ANSI coordinates 
standards for all facets of business. In 1979, ANSI chartered a new 
committee, labeled the Accredited Standards Committee (ASC) XI 2, to 
develop uniform standards for cross- industry electronic communications. 
According to the X12 committee, its function is to develop standards to 
faciliate electronic interchange of data relating to order placement and 
processing, shipping and receiving information, invoicing, and payment. 
The ANSI ASC X12 committee, using the basic structure and syntax es- 
tablished by TDCC, developed and continues to develop EDI standards 
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[Ref. 3; p. 66]. While TDCC-based standards and the ANSI X12 stand- 
ards are not identical, they use the same basic architecture and employ 
similar syntax rules [Ref. 3: p. 67]. 

B. ANSI X12 STANDARDS 

1. Organization of ANSI ASC X12 
The American National Standards Institute (ANSI) has made a 
significant contribution to the development of Electronic Data Inter- 
change transactions across industry lines, using standardized protocols. 
Since 1918, this organization has been responsible for approving engi- 
neering and industrial standards. ANSI does not actually establish 
standards. They are responsible for approving estandards that have been 
developed by committees of experts. ANSI uses a rigorous consensus- 
based process for the establishment of standards. As the official voluntary 
standard-setting organization for the United States, ANSI sanctioned the 
Accredited Standards Committee X12 (ASC XI 2) to develop the neces- 
sary standards. This committee was made up of representatives of 
commerical and industrial organizations, and vendors of services designed 
to facilitate the use of Electronic Business Data Interchange Standards. 
The scope of X12 is to provide standardization to facilitate 
interbusiness/institutional electronic interchange of transactions 'delating 
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to order placement and processing; shipment and receiving information; 
invoicing; payment; and application data. The X12 organization is 
structured into committees and subcommittees as showen in Figure I 
[Ref. 3: p. 77]. 

The two major committees are the Steering Committee and the 

Procedures Review Board who are responsible for the following; 

• Steering Committee performs administrative functions for X12 and 
provides coordination among subcommittees and task group. 

• Procedure Review Board (PRB) reviews all project proposals sub- 
mitted to the committee. It manages draft standards, standards 
maintenance, and compliance guidelines. [Ref. 3; p. 78] 

In addition to the two major committees, there are nine standing 
subcommittees. Six of the subcommittees represent functional area in- 
terests : product data, materials management, purchasing, finance trans- 
portation, and government. Three of the subcommittees deal with issues 
of a broader nature. The Technical Assessment Subcommittee reviews 
draft proposals to determine if they are within the scope of X12's activ- 
ities and also ensure the consistency within X12 standards. The Educa- 
tional and Implementation Subcommittee acts as the public relations arm 
of XI 2. In addition to the two major committees and nine subcommit- 
tees two other groups play a part in the X12 organization. The Data 
Interchange Standards Association (DISA) acts as the secretariat for the 
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Figure 1. ANSI XI2 organization 



X12 organization. DISA performs administrative functions such as 
printing, distribution, and storage of the standards. The X12 organization 



also participates in development of standards on an international basis 



by having X12 members serve as representatives to the North American 
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EDIFACT (Electronic Data Interchange for Administration, Commerce 
and Transport) board. 

Any individual or organization, whether a member of the X12 
committee or not, can request that a new standard be developed, or that 
a change be made to an existing standard. Such a request is usually sub- 
mitted to the secretariat, who forwards the request to the Technical As- 
sessment Subcommittee, as shown in Figure 2 [Ref. 3; p. 80]. 

If the request is within the scope of X12, the Technical Assessment 
Submittee forwards the request to the pertinent subcommittee for review. 
The subcommittee prepares a formal project proposal based upon the 
work request, which is submitted back to the Technical Assessment sub- 
committee for a consistency check with other standards. If the proposal 
passes this check, it is sent to the Procedure Review Board for one more 
vote on whether the proposal is within the scope of X12 and is consistent 
with other standards. If this vote is positive, then the proposal is referred 
back to the original subcommittee for actual standards development. 
Final approval authority for all business-related standards, not only EDI 
standards, rests with ANSI. Whenever ANSI receives a proposed standard 
from any Accedited Standards Committee, such as XI 2, ANSI sends the 
proposed standard out for public review and comment, a process that can 
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NOTIFY 



NOTIFY 





Figure 2. ANSI X12 maintenance/development flow 

take two to three years. Only after the review process is completed is the 
standard approved and released as an ANSI approved standard. In the 
EDI community, standards are considered approved once they have been 
accepted by the X12 committee. So, although most ANSI EDI standards 
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carry the offical title of draft standards, they are the standards in use and 
accepted by the EDI community [Ref. 3: p. 80]. 

2. Description of ANSI X12 standards 

The X12 committee continued development of business trans- 
actions which would support the use of computers in the day-to-day 

interchange of business data. The ANSI X12 standards consists of; 

• Transaction set standards 

• Data element dictionary 

• Data segment directory 

• Transmission control standards. [Ref. 2; p. 63] 

Transaction set standards define the format and context of data 
used within specified business documents, such as invoices. (The 
ANSI-approved transaction set standards are listed in Figure 3.) How- 
ever, while the invoice transaction set (810) conveys the functionality of 
the paper invoice, it does not contain as much descriptive information, 
since it is not intended for human reading. 

The data dictionary contains codes for types of information used 
in business documents. The data dictionary reduces vast amounts of in- 
formation to two-digit codes (called data elements), and therefore elimi- 
nates the need for descriptive information in an electronic document. 
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ANSI X12.M986 
ANSI X12.2-1986 
♦ANSI X12.3-1986 
ANSI XI 2.4-1983 
♦ANSI X12.6.1986 
ANSI X12.7-1986 
ANSI X 12.8-1986 

ANSI X12.9-I986 

ANSI X12.12-1986 
ANSI X12.13-I986 
ANSI X12.14-1986 

ANSI XI 2. 15-1 986 

ANSI XI 2. 1 6-1986 

♦ANSI X12.20-I986 
♦ANSI XI 2.22-1986 



Purchase Order Transaction Set (850) 

Invoice Transaction Set (810) 

Data Element Dictionary 

Remittance/Payment Advice Transaction Set (820) 

Applicadon Control Structure 

Request for Quotadon Transacdon Set (840) 

Response to Request for Quotadon Transacdon Set 
(843) 

Purchase Order Acknowledgement Transaction Set 
(855) 

Receiving Advice Transacdon Set (861) 

Price/Sales Catalog Transacdon Set (832) 

Planning Schedule \vith Release Capability Transac- 
don Set (830) 

Purchase Order Change Request Transaction Set 
(860) 

Purchase order Change Request Acknowledgement 
Transacdon Set (865) 

Funcdonal Acknowledgement (997) 

Data Segment Directory 



Figure 3. American national standards for electronic business data 

The data segment dictionary provides the definition and formats for 
data segments. These data segments consist of a precise sequence of data 
elements, separated by delimiters. 

The transmission control standards define the formats for the in- 
formation required to interchange data. Defined within the transmission 
control standards are data element delimiters, transaction set separators. 
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and transmission envelope formats. Figure 4 [Ref. 2: p. 67] illustrates a 
typical paper invoice. Within the electronic invoice, as with each trans- 
action set, there are three general areas that relate directly to the format 
of the printed document : 

• The header area contains preliminary information that pertains to the 
entire document, such as the date, company name, address, p.o. 
number, number, and so on. 

• The line item area encompasses the actual business transaction and 
includes such information as quantities, descriptions and prices. 
Again, in EDI, each line is called a data segment, and each item 
within the segment becomes a data element. 

• The summary area contains control information and other data that 
relate to the total transaction. 

To generate electronic documents, the information contained in 
the invoice is replaced with the appropriate X12 codes, as compiled in the 
data dictionary. Data elements are separated by asterisks (*); data seg- 
ments are separated by "N/L" indicators. A line-by-line comparison of the 
X12 invoice and the paper invoice of Figure 5 [Ref. 4; p. 53] appears in 
Figure 6 [Ref. 4: p. 54]. 

In Electronic Data Interchange, each line is called a segment and 
each item within the segment becomes an element. 

The benefits derived from the use of a standard format for a spe- 
cific transaction set are many fold. In one surveyed organization, it was 
estimated that more than 400 different purchase order formats weYe being 
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Figure 4 . ANSI X12 interchange structure 



received weekly. The potential EDI user should recognize the important 
benefits that result from the use of a single, standard format purchase 
order for all buying and selling activities. Even the company which de- 
sides not to transmit business data electronically could benefit from the 
use of standardized transactions. This simplification in transacting data 
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Purchase Order 

To: Selling Party 400061 

123 E. West St. 

Anytown. USA 99999 


Dale: 04/23/84 

Buyer Contact 
Joan Buyes 


Page 1 of 1 

5KK3-05530 
This Number Must 
Appear on all Boxes. 
Packages, Shipping 
Documents & Invoices. 


From: Buying Party 162 

444 W East Ave 
Downtown, USA 99999 


Ship: Ship To Party 1100 
Receiving Dock 
100 Mam St. 

Downtown. USA 99999 






Ship 


FOB Freight Allowance 


Terms 


Ship Date Due Date 


Truck Mil! 


Less C/L FA 


2/20LCC 


05/13/84 05/15/84 


Line 

No. 


Your 
Item No. 


Our 

Item No. 


Item Description 


Unit 

Price 


Quantity 


UOM 


Item 

Due Date 


1 


20784 


1147560 


23x35 81 OC Shasta 


56.75 


16 


Ctn 


05/15/84 








Gl Bk Whte 






16 


Ctn 


05/22/84 














16 


Ctn 


05/29/84 


2 


14096 


1 1 24486 


23x35 880 Shasta 


59 50 


16 


Ctn 










Suede Bk Wh 










3 


51193 


1107820 


23/35 Offset Opaq 


46.00 


16 


Ctn 










Vellum 































Figure 5. Original purchase order 

is supported by widespread acceptance of ANSI X12 business data inter- 
change standards. 

Figure 7 further illustrates the ANSI transaction development 
process leading to standards publication. A number of project teams and 
subcommittees are involved. Firms without participation in the standard 
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Formal for EBDI 
Sf'850‘0'100 N/L 



RelaleO Pufd»aso Oder SeclKxi 



DE G • 00 *SA-5KK3 05530* * *8'l0^23 N/L 



NrSE'92M00061 N/L 



Purchase Order 



Dale: 0^/23/8^ 



5KK305530 
This Number Must 
Appear on all Boxes. 
Packages. Shippir^ 
Documenls & Invoices. 



To 



400061 



Ship 



NTBY* •91*162 N/L 
PEP* SO -Joan Buyes N/L 
NrST**9ri100N/L 

ITD*0rO3*2*’2ON/L 
SHH‘SD*010*840513N/L 
SHH* 00*002*8405 15 N/L 
FOB ‘PP* Ml ‘Less C/L FA N/L 
T02*0*E N/L 

POr 1*48*01*56 75*QT*IN*1 147560*VN*20784 N/L 
SCH * 1 6 * CT 002 * 8405 1 5 N/L 

SCH * 1 6 * CT * * * * 002 * 840522 N/L 
SCH * 1 6 * CT 002 * 840529 N/L 

POl*2*l6*CT*59 5*OT*IN*1 124486*VN*14096 N/L 
POl*3*16*CT*46*OT*lN*l 107820*VN*51 193 N/L 

Cl I *3*80 N/L 
SE *13*8400 N/L 



Selling Parly 
123 E West St 
Anytown. USA 99999 
From- Buying Party 162 
444 W. East Ave 
Downtown. USA 99999 

Buy$r Contact 
Joan Buyes 

Ship To Party 1 100 
Receiving Dock 
100 Main St. 

Downtown. USA 99999 



Ship Date 


Due Date 


05/13/84 


05/15^4 


FOB 


Freight Allowance 


Mill 


Less CA- FA 



Line 

No. 


Your 
Item No 


Our 

Item No 


Item Description 


Unit 

Price 


Quantity 


UOM 


Item 

Due Date 


1 


20784 


1 147560 


23x35 8100 Shasta 




16 


Cln 


05/15/84 








Gl Bk Wtite 




16 


Cm 


05/22/84 












16 


Cln 


05/29/84 


2 


14096 


t 124486 


23x35 880 Shasla 


59^ 


t6 


Ctn 










Suede BkWh 










3 


51193 


1107820 


23/35 Ollsel Opaq 


46 00 




Ctn 










Vellum 




— 


— 


— 



Terms 



2/20LCC 



Ship 



Truck 



Figure 6. Translation of purchase order 

setting process should familiarize themselves with the process and con- 
sider some form of participation [Ref. 4: p. 52]. 



I 
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• materials 

MANAGEMENT 

• TECHNICAL 

• international 
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• PRODUCT DATA 

• FINANCE 




COORDINATE, APPROVE, PRESENT 
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STANDARDS INSTITUTE 
(ANSI) 



DEVELOP 

TRANSACTIONS 



V 

ANSI PUBLISH 
STANDARDS 



Figure 7. Transaction development process 

C. EDIFACT 

Until relatively recently, most UK and European EDI users have 
based their standards on the United Nations Trade Data Interchange 
(UNTDI) syntax (United Nations Economic Commission for Europe: 
Guideline for Trade Data Interchange). This system is highly flexible and 



17 



provides guidelines on syntax (character sets and transmission formatting 
rules) and on segment and message construction. There is also an asso- 
ciated directory of data elements, data elements being the basic compo- 
nents of an EDI message [Ref. 3: p. 60]. 

It should be noted that recent initiatives have been taking place to 
bridge the differences which exist between the UNTDI s}mtax and the 
American National Standards Institute's equivalent system known as 
ANSI XI 2. The objective is to allow the building of EDI standards which 
will be valid for trade across international boundaries. The project began 
life as a joint effort between European and American EDI experts, and 
was christened Joint Electronic Data Interchange (JEDI). Following the 
agreements reached by the JEDI representives on principles and syntax, 
the project has received widespread support from the many countries and 
user communities and, importantly, from the ECE (Economic Commis- 
sion for Europe). It is known as Electronic Data Interchange for Ad- 
ministration, Commerce and Transport (EDIFACT). 

The new EDIFACT EDI syntax has alway been accepted as a full 
international standard: ISO 9735. The EDIFACT syntax is not greatly 
dissimilar from UNTDI, but there are some important differences which 
also have an impact on the method of standard message design. Inter- 
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national standard messages (UNSMs) are now being developed as part 
of the EDIFACT project, which is coordinated by the EDIFACT board 
and steering committee. Advanced drafts of the invoice and order files 
are already available. Other files are being developed as quickly as possi- 
ble in order of perceived priority. UNSMs are being based on the United 
Nations data element directory with new elements being created as nec- 
essary. They also use the concept of qualifiers, well established in ANSI 
X12 standards. Qualifiers are codes used to confer a specific function 
or identify on a generic data element or segment. Further details on the 
availability of UNSMs and on the EDIFACT project in general are ob- 
tainable from the UK Simplification of International Trade Procedures 
Board (SITPRO). The EDIFACT standards or syntax will not imme- 
diately or indeed ever supercede or outmode standards based on UNTDI, 
which have a large, established and successful user base. Nevertheless, 
there is growing support in principle for the evolution toward EDIFACT 
standards as the solution for EDI across national boundaries [Ref 5; p. 
31]. 
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D. CALS 



1. Background 

We have witnessed a rapid growth in technology and in product 
complexity, and with that growth has come an increasing volume of 
product information in recent years. As the systems we develop become 
more complex, the teams needed to design and develop these systems 
become more specialized. Sophisticated documentation and information 
exchange are necessary to hold an organized development effort together. 
Governments, contractors, subcontractors, and developments within 
companies all need to share information rapidly and effectively. When- 
ever information is unusable or needs to be converted to another form 
or retyped into a different computer system, there is wasted effort and 
delay in the development cycle, which costs time and money. 

The United States Department of Defense (DoD) has recojgnized 
the need to increase the efficiency and productivity of development efforts 
and the quality of final products. The DoD plans to achieve this by 
modernizing the information systems that support the life cycle of defense 
weapon systems. By specifying the form and structure of weapon-systems 
data bases, the DoD is promoting more effective, accurate, and efficient 
information exchange among DoD agencies, military services, and indus- 
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try partners. The effort was launched in 1985 as a DoD task force project 
through a directive from the Deputy Secretary of Defense, William H. 
Taft. Known as the Computer-aided Acquisition and Logistics Support 
(CALS) initiative, it has become a committed direction for all U.S. 
weapon systems. The product of this initiative is a set of military stand- 
ards and specifications that define formats, structures, and protocols for 
the information that is exchanged [Ref. 6: p. 4-1]. 

While the DoD and its industry partners are designing and imple- 
menting CALS systems, other government agencies, manufactures of 
high-tech products, and governments worldwide, particularly Canada and 
European countries, are becoming aware of the benefits of such a system. 
Some of these organizations have begun to adopt the CALS standards 
and specifications, in whole or in part, as the basis of their information 
systems. Thus, what started as a DoD initiative is becoming a global 
model for information systems supporting complex technical products of 
the future. 

The initial phase of CALS standardizes the exchange of textual 
and graphic documentation for both printed copy and digitally commu- 
nicated information. The long-term goal of the CALS initiative is a 
totally integrated weapon-systems data base in which all information 
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about a weapon system resides. Rather than exchanging information on 
various media, such as paper or magnetic tape, authorized users will ac- 
cess a data base to get the information they require. Thus, users who need 
accurate, up-to-date information can get it quickly and efficiently. The 
immediate and long-term benefits of a CALS system are substantial, in- 
cluding; 

• Reduction in the product development cycle 

• Reduction in development and service costs 

• Increase in the accuracy of product information 

• Improvement in the integrity and readiness of the weapon system. 

[Ref 7: p. 16] 

2. What is CALS? 

Computer-aided Acquistition and Logistics (CALS) is a strategy 
that the DoD and its industry partners are using to enable and accelerate 
the integration of the digital technical information that is associated with 
the acquisition, design, manufacture, and supP'^rt of a weapon system. 
CALS provides for a transition from current, paper-intensive processes 
to the efficient use of digital information technology. The first phase of 
the CALS initiative focuses on technical publications and the information 
used to create them. Traditionally, the process of acquiring an 
information-processing system has been difficult and expensive. Each 
weapon system has its own requirements; therefore, building the appro- 
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priate information-processing system means continually reevaluating, up- 
grading, and reconfiguring the existing equipment and software, and 
possibly migrating to an entirely new system. The CALS approach to this 
challenge is to put all the information about the product, from design 
specification to engineering drawings to project management data to 
technical manuals, in an integrated data base. If all the information is in 
one data base in standard formats, the need to covert or reformat the 
information is greatly reduced. Those who need to use the information 
or contribute to the data base simply access the data base through defined 
query or retrieval- interfaces. A central data base helps users more easily 
access information, in essence bringing the information to the users. It's 
their responsibility to use a system that can communicate with the data 
base and accept and deliver information in the proper format. 

An integrated data base is the solution for which the CALS com- 
munity is striving. However, there are a number of hurdles to overcome 
first, one of which is standardization of information and data formats. 
Therefore, the immediate goal is to improve the process of exchanging 
information among different computing systems. In the initial phase of 
CALS the DoD, working with industry steering groups, has defined se- 
veral standards and specifications. Drawing from existing international 
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standards, the CALS committees have defined the acceptable formats for 
textual, graphic, image, and engineering information. Figure 8 [Ref. 7: 
p. 14] provides a brief summary of the primary CALS standards and 
specification that the DoD has defined. 

By standardizing the format of information, the DoD can be sure 
that, regardless of what computer system the information comes from, 
other computer systems can process it. It's up to everyone involved to use 
a system that can accept, process, structure, and deliver the information 
in a format that conforms to the CALS standards and specifications. 

3. Relationship between EDI and CALS 

The relationship between EDI and CALS can be summarized by 

the following positions taken by DoD and NIST. 

• December 1988, MIL-HDBK-59; CALS will use EDI transaction sets 
for exchanging technical information. 

• March 1989, DoD recommendation are link CALS data and EDI 
data into one protocol. As proposed by automotive industry action 
group (AIAG) and DOD memo stating that a "common technical 
approach" be taken to ensure "complementary implementation" of 
CALS and EDI. 

• Sept 1989, Dept of commerce (NIST) published "Transmission of 
CALS 1840A technical data through the use of X12 EDI transaction 
set 841". 

• EDI transaction set 841, Specifications/Technical Information, has 
been specified in ANSI XI 2.51 by its Product Data Subcommittee. 
It provides for the exchange of complete or partial specifications or 
technical information related to products and services [Ref. 7: p. 22]. 
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Standard or specification 


1 Oatcrlpllon 


Military Standard MIL-STO-1840A: Automated Inter- 
change of Technical Information 


An "umbrella" standard mat describes all of the 
requirements for delivering CALS documents. 
MIL-STD-1840A refers to the military specifications 
listed below, it also describes how information is to 
be loaded onto magnetic tape for delivery. 


Military Specification MIL-M-38784B Manuals, Tech- 
nical: General Style and Format Requirements 


Describes the general requirements for military doc- 
umentation, from content and style to page-layout 
specifications. 


Military Specification MIL-0-28000: Digital Represen- i 
tation for Communication of Product Data: IGES Appli- 
cation Subsets 


1 Describes the format for graphics files containing 
j engineering information. 


Military Specification MIL-M-28001 and MlL-M-2800l A: 
Markup Requirements and General Style Specification 
for Electronic Printed Output and Exchange of Text 


Describes the format for text files Basically. 
MlL-M-28001 defines Standard Generalized Markup 
Language (SGML) document type definitions (DTD) for 
CALS documents. A later section of this book 
describes how CALS uses SGML. 


MIL-R-26002: Raster Graphics Representation in 
Binary Format, Requirements for 


Describes the format for raster (dot-oriented) graphics 
files. 


MIL-D-28003: Digital Representation for Communi- 
cation of Illustration Data: CGM Application Profile 


Describes the format for vector (line-oriented) 
graphics files. 



Figure 8. CALS standards and specification 
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HI. ANALYSIS OF TRANSACTION AND DATA MAPPING 



A. TRANSACTION AND DATA FLOW 

The introduction of Electronic Data Interchange can impact the 
documents traditionally used to transmit necessary information. EDI can 
eliminate nearly all external paper. This section has two major objectives. 
The first is to document the flow of paper in a traditional manual pur- 
chasing and material management system. The second objective of this 
section is to explain how the paper flow may change as a firm evolves 
from a manual to a computerized purchasing system with EDI. 

In a manual purchasing system for a typical purchasing department, 
a paper flow is established to support its routine, day-to-day activity, and 
this flow provides information to a multitude of different individuals lo- 
cated in several functional departments. This paper flow has developed 

over time into a series of procedures that meet four basis concepts; 

• The flow of paper permits the efficient use of purchasing resources 
in conducting the routine activities of the department. Most paper- 
work is done by clerks instead of managers. 

• The flow of paper provides needed information to the various de- 
partment that are affected by the placement of an order, e.g., manu- 
facturing control, inventory control, receiveing, accounting, etc. 

• The standard flow of documentation is clearly defined. The reason 
for this standardization of procedures is so that the multitude of 
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clerks supporting the system can process the documentation with 
minimum effort and uncertainty. 

• The flow of documentation permits managerial discretion. When 
conditions arise that are not routine or normal, responsible managers 
are informed about the condition. These managers can take correc- 
tive action before any problem arises. [Ref. 4: p.37] 

The flow of paper in a manual purchasing system such as the one il- 
lustrated in Figure 9 [Ref. 4: p.39] accomplishes these conditions. 

The normal paper flow showm in Figure 9 is quite complex because of the 
continuous flow and enormous quantitites of paper generated and 
stored. Unless these documents are organized in a systematic manner, 
much of the information contained in tl.'ese documents would be useless 
to purchasing and other departments within the firm. Figure 10 [Ref. 4; 
p.40] shows a simplified inter-firm transfer of documents on a manual 
basis. 

In a computerized purchasing system, EDI has been defined as the 
exchange of business information from one firm to another in machine 
readable form. EDI was developed to eliminate the external documenta- 
tion between a supplier and buyer, not the internal paper. A computerized 
purchasing information system with or without EDI is needed to elimi- 
nate much of the internal documentation. Many firms have computerized 

I 

purchasing information systems without EDI that are quite sophisticated. 
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Figure 9. Manual system 

Such information systems have various modules for on-line purchase or- 
der, purchase order change notice, receiving inspection, and inquiry. 
They also have interfaces with accounts payable and requirements plan- 
ning. By and large, these sophisticated purchasing information systems 



28 
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Figure 10. Manual system 

have eliminated much of the internal paper generation through intelligent 
design and without the use of EDI [Ref. 4: p. 40]. 

EDI involves external communication with suppliers. Figure 11 [Ref. 
4: p. 42] illustrates the communications between buyer and seller for a 
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Buyer-Seller Communication 




Figure 11. EDI system 

fairly sophisticated EDI system. The elimination of paper requires a well 
planned sequence of events. Even though the EDI system is electronically 
sophisticated, some purchase orders, acknowledgement, requests for 
quote, etc., for certain purchase items may still be sent by mail. It is also 
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desirable to maintain a direct communication channel between the buying 
firm and one or more suppliers, even though a third-party network is in 
operation. This direct communication can be by means of computer, 
telephone, and/or mail.* In sum, an integrated purchasing/EDI system, 
where both digital and manual methods of communication are available, 
is a very desirable type of system configuration. An integrated 
purchasing/EDI system such as the one pictured in Figure 1 1 can elimi- 
nate most of the external physical documentation and still maintain the 
flexibility critical to any purchasing system. 

Several issues arise for a firm operating in an EDI environment. One 
key issue concerns the storage of electronically transmitted purchase 
documents. A decision concerning an appropriate storage mechanism, 
e.g., magnetic tape, hard disk, floppy disk, microfiche, etc., must be made 
by all firms involved in the EDI system [Ref. 3; p. 38]. 

Another issue concerns the operation of a parallel purchasing system 
during the initial phase of EDI implementation. Both hard-copy of the 
purchase order and the EDI transaction would be sent to suppliers. Par- 
allel systems are a necessity, but frequently short lived. For one firm, the 

I Multiple third-party networks including a gateway may be used to support EDI. From in- 
formation gathered in a surv’ey, it seems probable that the use of third-party networks will increase 
significantly in the future. 
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parallel system lasted only 3-6 weeks and was discontinued as soon as 
each each supplier gained confidence in the EDI system [Ref. 3: p. 42]. 

A third issue raised by the implementation of an EDI system concerns 
job content. The job of the typical purchasing professional in the EDI 
environment can change significantly. Purchasing personnel will spend a 
much smaller percentage of their time firefighting and a larger percentage 
of their time planning purchases. The change in work flow for buyers 
should be carefally managed. Buyers should continue to review orders. 
After the paper begins to disappear, they should print logs of purchase 
orders and change notices placed during any day. They also have to keep 
a purchase order number as a control number for reference purposes with 
vendors. It is a good policy to eliminate only one physical document type 
at a time and initially keep the set of vendors small [Ref. 3: p. 43]. 

The implementation of EDI can create a more effective receiving 
function through the better scheduling of receipts. As the paper disap- 
pears, the receiving function will be forced into a closer integration with 
the ordering function. The information concerning order status and 
shipping which at one time was available primarily to purchasing can now 
be used by the receiving function for a more efficient operation. With 
the advent of more frequent orders and a shorter purchasing cycle time, 
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efficient receiving operation is important to the proper functioning of the 
entire procurement and manufacturing system [Ref. 3: p. 45]. 

B. DATA MAPPING 

Data mapping extends the EDI process by using the values received 
as though they had been entered into the user's information system locally 
[Ref. 8: p. 2j. A purchase order received electronically is automatically 
entered into the system as though it had been given verbally to an order 
clerk and hand-entered. A shipping notice is received providing location 
information on an inbound shipment. The values are automatically stored 
in the interactive oatabase which allows users to access the information 
at any time. On the transmitting side, an invoice is developed from the 
accounts receivable software and transmitted to the recipient without 
human intervention at any step of the process. The computer-to-computer 
portion of the process (Figure 12) [Ref. 8: p. 2] is what we often mean 
when we say we are doing EDI. The answer is where the efficiencies lie. 
Transmitting a purchase order electronically will assuredly save time and 
promote greater accuracy, but only to the point where the purchase order 
appears as output of the receiving company's corporate information sys- 
tem. The computer system then actually processes the purchase order, 
fully realizing the efficiencies. Data mapping is the process that will ac- 
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OUTBOUND 



Flow of an EDI Transaction 





INBOUND 



Figure 12. Flow diagram of computer-to-computer EOI 

complish this extra step. By taking the values produced by the translation 
software and automatically integrating these values into procedure calls, 
database assignments, or some combination of these, the most inefficient 
part of the system can be eliminated. We develop a conceptual de- 
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scription of data mapping under the following five scenarios [Ref. 8: p. 

4]. 

1. The paper system 

A paper system (Figure 13) [Ref. 8: p. 8] does not carry the data 
beyond the translation process. On the receiving side, EDI transmissions 
are translated and pointed out for further action. The further action may 
be the use of these values to enter data into an automated system that is 
not yet integrated with EDI software. It may be the begining of a totally 
manual process. On the transmitting side, data is entered into the EDI 
translation software via a keyboard. Most software packages provide the 
user with a great deal of assistance in this process via user-friendly input 
screens, template generation, and code selection capabilities. Paper EDI 
systems are used most often by small companies who are not prepared to 
fully integrate EDI. In many cases they have been persuaded by a major 
trading partner to begin doing business via EDI. They may not be able 
to cost justify the development of a fully integrated EDI system. Paper 
systems are sometimes used by larger companies as part of a pilot effort 
or as a means for getting into EDI quickly with the intent of integrating 
later. Since a paper system is a complete system, it is a logical step in the 
build- a- lit tle-test-a- little process. 
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Figure 13. Paper EDI system 



2. Integrating with the existing database 

This scenario consists of the most basic integration mode, that of 
simply interfacing the EDI translation software with an existing database. 
The implication of this type of activity is that we will be dealing strictly 
with static data values. The translation software uses an intermediate flat 
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Figure 14. Integrating EDI ^^ith existing corporate database 



file to pre-stage raw data for translation into EDI transaction sets and 
as output when interpreting EDI transaction sets. The integration in- 
volved is the process of programatically mapping values between the flat 
file and the appropriate locations in the corporate data base (Figure 14) 
[Ref. S; p. 10]. This involves an analysis of the corporate use of each el- 
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ement in each transaction set to determine what values will be transported 
to what database locations. This programming process is the origin of 
the term data mapping which is frequently applied to all of the aspects 
of application integration described in this section. We shall use the term 
database mapping to describe the process of mapping only static data, that 
which will not be used immediately but will be stored for future use. The 
more generic data mapping will be used to include application integration, 
the immediate employment of data values as part of a process or proce- 
dure call where the data values are used as parameters. 

3. Integrating with existing applications/processes 

This scenario is similar to that of data mapping except that instead 
of mapping raw’ data values from an intermediate file to a database, data 
are extracted and mapped into an existing procedure call w'hich will than 
be applied in its normal manner to the corporate system (Figure 15) [Ref. 
8; p. 11]. An example of this w'ould be incorporating EDI into an existing 
system that allows the execution of computerized purchase orders. The 
integration of EDI would permit automatic execution of purchase orders 
received via EDI transaction sets. Note that, in mapping to a database, 
almost any type of transaction set can be received and mapped. The dif- 
ference in the scenario being described is that only those transaction sets 
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Figure 15. Integrating EDI >\ith e.xisting corporate processes 

can be integrated for which an automated corporate process (e.g., placing 
or receiving an order, sending or receiving an invoice) already exists. 

4. Developing new applications/processes based on EDI 

In this scenario, the EDI user is interfaced with developing systems 
or subsystems for EDI transaction sets which do not correspond to 
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Corporate Processes 




Database 



Figure 16 . Developing new processes based on EDI 



processes currently being used in the corporate system. This type of ap- 



proach presupposes either a new type of business being created by the 



introduction of EDI or the recognition of the need for new internal 



processes due to the advent of EDI. In either case, instead of applying 
the data to existing processes as described in the preceding subsection, 
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new corporate processes will be developed which include integrated EDI 
as part of the application. These would, in turn, be integrated into the 
overall corporate information system (Figure 16) [Ref. 8: p. 13]. 

5. Fully integrated application/EDI system development 

The final scenario which will be discussed in this section is that 
of including EDI integration in the design of a new corporate business 
data processing system (Figure 17) [Ref. 8: p. 15). Many new design 
considerations, in addition to those normally experienced in a system 
development process, will be encountered. Among these are the selection 
of translation software. Selecting or developing software that can be 
coupled directly with applications modules could eliminate or reduce the 
need for interface files. Proceeding with the development in this manner 
could produce a very efficient, tight coupling between the modules of the 
system and the translation software. These and other complex decisions 
are involved in the pursuit of this type of development. 
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Figure 17. Fully integrated application/EDI system 



42 



IV. HARDWARE AND SOFTWARE REQUIREMENTS 



A. HARDWARE REQUIREMENTS 

There is actually no such thing as unique EDI hardware. EDI software 
is available for mainframes, minicomputers, and microcomputers. All it 
takes to do EDI is a computer of some type, a communications modem, 
and software. The most common hardware and software combinations 
used to perform EDI are shown in Figure 18 [Ref. 9: p. 90]. As shown 
in the Figure, three basic options exist: mainframe only, microcomputer 
only, and microcomputer as a front-end processor to a mainframe. 

The minimum microcomputer configuration to implement an EDI 
system consists of: [Ref. 4: p. 65] 

Computer 

• Processor - 16-bit minimum 

• Memoi7-256kb, expandable 

• Real-time clock 

Screen Display 

• 24 line X SO character 

Disk Storage 

• 2 dual-sided floppy-360k 

• Optional : Hard Disk 10 MB 
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Figure 18. Software/haidnare options. 

Communications 

• Hardware - RS232 serial interface port 

• Modem - 1200 to 9600 Baud, Bell 201 C and 208 B compatible for 
2780 3780 emulation, bisynchronous 

• Communication lines - Bell 208 B or equivalent 

• Software - capable of communication with partner's PC or 
mainframe 



Operating System 
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MS-DOS. Unix, or UNIX compatible 



Prugrammi/i^ Language 

• Varies with choice of third parties and industry 

• Recommend ANSI XI2 

Primer 

• Dot matrix, 160 character sec, SO column or 136 column 

• parallel or serial interface 

If we include the third-party support as an option, there are four different 
system approaches regarding hardware platform for EDI, as illustrated in 
Figure 19: 

• PC-based configuration 

• mainframe based configuration 

• PC-to-mainframe configuration 

• third-party support. 

The advantages and disadvantages and the costs of these four approaches 
are summarized in Figure 20. 

B. SOFTWARE REQUIREMENTS 

EDI software consists of computer instructions that translate infor- 
mation from unstructured, company-specific format to the structured 
EDI format and then communicate the EDI message. EDI software also 
performs this activity in reverse (receives the message and translates from 
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Figure 19. Hardware platform for EDI 



Standard format to company-specific format). lOI software can be de- 
veloped in-house or it can be purchased from a number of commercial 
software vendors. EDI can be performed on various types of computers 
and software is currently available for EDI applications using mainframe 
computers, minicomputers, or microcomputers (PCs). The major func- 
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Sample Costs for Buyer 


Advantages 


Disadvantages 


Hardware: $4000.00 
Software : $1000.00 
to $10000.00 


Lowest system cost 
Allows for multiple 
stations 


Limited data volume 
Harder to secure system 
Require each partner 
Same baud rate 
Same protocol 


Hardware : $10000. 

to $100000. 
Software : $1000. 

to $20000. 


Can handle high 
volume of data 
Larger Data Base 
Better security 


Costs of hardware 
Same baud rate 
Require each partner 


Hardware : $4000 
Software : $1000 

to $10000 


Suppon Remote job 
Handle higher volume 
One-to-many EDI 

system i 


PC user limited 
Require each partner 
Same baud rate 
! Additional software 


Hardware: $4000. 

to $100000. 
Software : Variable 


Better security 
Mailbox services 
Multiple destination 
Access to satalies 
Allow long distance 


Added costs 
Addsadditional link to 
the EDI transaction cycle 



Figure 20. Advantage and disadvantage 



lion that EDI software performs is formatting or translation. Formatting 
software generally uses a table structure to perform the translation. The 
software includes tables consisting of the standard data dictionary and 
syntax rules for the data segments and elements of a given EDI trans- 
action set. The actual transmission of the EDI message is controlled by 
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communications software. This software manages and maintains phone 
numbers of trading partners, performs automatic dialing, and also 
produces an activity log. 

Figure 21 [Ref. 3: p. 92] shows the normal sequence of activities per- 
formed by EDI software for both incoming and outgoing EDI. 

There are a number of software categories associated with an EDI 
system. These include: 

• Database management software: Designed to systematically organize 
data into files for easy access, retrieval, and update. 

• Format/conversion or translation software: User information input 
into transaction format (ANSI XI 2) and then converted to the elec- 
tronic transmission protocol. Also capable of converting transmitted 
data from the communications protocol to the transaction format 
(ANSI X12). 

• Communication software: Controls the data being transmitted via 
phone lines to and from EDI partner. [Ref. 3: p. 66] 

EDI software may be one of the following: 

• Internally developed software 

• Commercially available software 

• Database management software: ranges from $199.00 to $3,000.00. 

■ Communications packaged software; ranges from $99.00 to 

$1,000.00. 

■ EDI format/protocol software 

Most of the following features are available in commercially devel- 
oped softw'are, and should be included in any in-house developed soft- 
ware. 
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Figure 21. Function of EDI soft^vare 

• Table-driven structure 

• Editing capability 

• Customize ease 

• Audit options 

Three major factors should be considered in determining whether your 
organization should buy a commercially available software pack; or it 

should develop the software in-house. They are: 

• In-house resources 

• Maintenance required 
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Company policy 






If your organization decides to buy rather than develop software in- 
house, you will be faced with selecting among a number of software ven- 
dors. In evaluating commerically available software packages and vendors, 

four major factors should be considered: 

• Meeting needs 

• Company experience 

• User friendly software 

• Vendor user-friendly 
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V. NETWORKING REQUIREMENTS 



A. TELECOMMUNICATIONS INFRASTRUCTURE 
1. COMMUNICATIONS STRUCTURE 
The objective of the EDI system is to enter specific EDI trans- 
action data once and then transmit that data in a computer readable 
format throughout the complete EDI cycle. Four approaches for 
computer-to-computer transfer of EDI transaction are described below 

and illustrated in Figure 22 [Ref. 4; p. 68]. 

• Mail or courier service delivering magnetic tape or diskette; Primary 
considerations of this method might be cost of transport, security of 
connection, and speed of delivery. 

• Point-Point connection between partners: Both partners accommo- 
date the same communication protocols and ANSI X12 format. 
Some considerations are cost of connection justified by volume of 
data, and speed of delivery. 

• Value added network without translation: It provides mailbo.x ser\'ice 
for both partners, accommodating ANSI X12 formats. Specific 
considerations include; 

- Easy adaptation of each partner's own line speed, protocol, 
multi-destination, time of day, etc. 

• Value-added network with translation; It provides mailbox and X12 
standard translation. Partners do not have to worry about translating 
standard formats, or do they negotiate line speeds, protocols, multi- 
destinations, and times of day. 
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Figure 22. Approach for computer-to-computer transfer 



A Starting point for determining the most suitable communications 
services is to decide where in the organization the EDI application will 
be operated and who the end user will be. Invoice keying, order entry, 



52 



just-in-time purchase, stock updating, delivery, customs and excise no- 
tification, and EFT (Electronic Funds Transfer) may occur in different 
departments staffed by different users. Four scenarios are examined to 
indicate the data communications options a company might adopt when 
introducing EDI. They are referred to as Integrated-External and 
Integrated-Internal (where applications require connection to the main 
process of the company in order for EDI to function) and Partitioned- 
External and Partitioned-Internal. The partitioned scenarios are situ- 
ations where the EDI requirement applies to one end-user department for 
document exchange outside the company. The most suitable network 
solution and most appropriate protocols will be different for each of these 
scenarios [Ref. 5: p. 156]. 

a. Integrated-Internal network structure 
The corporate network is already in place. The existing network 
would, typically, be based on a centralized star network configuration 
possibly with multiplexing or a peer-to-peer communications service 
based on a switched network configuration. Examples of these config- 
urations are SNA networks and X.25 packet switching networks, respec- 
tively. 



53 



b. Integrated- External network structure 



As with the internal structure, a corporate network is in place. 
External communications are also set up, perhaps bilaterally on private 
circuits or via PPSN (Public Packet Switched Network). The need for 
scheduling processing of documents will dictate the use of a store-and- 
collect facility which will typically be an external mailbox system. Inte- 
grated structures should consider all permanent external applications 
(EDIamong them) so as to achive economies of scale. A PPSN with X.25 
interfaces, which offers the exchange of transactions securely to and from 
the company to more than one destination, best provides this sort of ex- 
ternal network connection. 

c. Partitioned-Internal network structure 
This situation is a point-to-point requirement, typically PC to 
mainframe. The cheapest way of setting this up is by using the PSTN 
(Public Switched Telephone Network) as an adjunct to the mainframe's 
network ports, or a LAN where this exists. If volumes are high or security 
considerations rule out the PSTN, a private circuit connection to the 
corporate network will be required. 
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d. Partitional-External network structure 



This is a simple configuration requiring no connection to the 
corporate network. The EDI application is likely to be developed on a 
PC and external communications will probably be via the PSTN to the 
EDI clearing house or correspondent. 

2. PROTOCOLS 

The main types of protocol and their suitability for an EDI com- 
munications service are considered first. Protocols in this instance refer 
to the station-to-station procedures for handling the correct transmission 
of data across a link and the data stream. The main protocols relevant 
to EDI are given below [Ref. 10: p. 26]. 
a. 3780 and 2780 

These are block-mode protocols used for one way at a time 
(half duplex) exchange of data in batch. Commonly referred to as Remote 
Job Entry (RJE) they are used between processes--PC to mainframe, de- 
partmental mini system to mainframe. Partitioned network structures will 
find this method most suitable as it offers a widely available means of 
transmitting files error-corrected over the PSTN. The characteristics of 
the files are likely to be low volumes of data generated in a stand-alone 
PC. Most communications hardware suppliers support these protocols. 
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They have been established for many years and they originate from the 
early IBM data processing environment. 

b. 3270 and 3770 

Whereas 2780/3780 is the de facto batch protocol from the BSC 
environment, 3270 is the de facto screen display data stream. It is nearly 
always associated with SNA/SDLC (Systems Network Architecture/ Syn- 
chronous Data Link Control). SDLC is the link level transport mech- 
anism, usually point-to-point cluster controller to FEP (Front End 
Processor), supporting and protecting the integrity of the 3270 data 
stream across the link. 3770 is used for batch work in the SNA environ- 
ment. When the network structure fits the integrated network scenarios, 
3270 and SDLC are appropriate. 

c. VT100, TTY and C03 

In very many processes, documents are exchanged interactively 
by an operator or admin clerk filling in forms on a workstation attached 
locally or remotedly to a host system. In addition to 3270, C03 and 
Screen VTIOO apply. C03 is similar to 3270/SDLC in concept and exists 
in the ICL (International Computers Limited) environment. VTIOO is a 
character- interrupt protocol and is usually restricted to terminals which 
are directly attached to a DEC host system. 
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d. X.25 



The X.25 protocol is the standard method of interfacing to 
packet networks. It is made up of three levels: the physical or line level 
where the control of the electrical interface is defined (V.24, V.35 and 
X.21bis); the link level which, with HDLC, ensures that data is trans- 
ported across a link with integrity and under the control of both ends of 
the link; and the packet level where data is split into packets and are dy- 
namically multiplexed such that many calls to many addresses can be 
transported simultaneously on a single link. X.25 defines the interface 
between DTE (Data Terminal Equipment) and the packet switch. The 
manner in witch data is handled within a network is not merely a function 
of the X.25 protocol but the design of the network itself. X.25 is suitable 
for the integrated network structure scenarios where corporate communi- 
cations are based on X.25. Partitioned network structures can also 6pt for 
X.25 because the protocol is firmly supported by PC communication card 
manufacturers as well as all the main data processing officer automation 
equipment manufactures [Ref. 5: p. 159]. 

3. NETWORKS 

More significant than the protocol is the network which is to be 
selected for EDI. This is because the selection can involve investment 
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decisions which are far more important, particularly for the integrated 
network structures. In selecting the appropriate type of networking for 
EDI, the breadth of applications which the network is required to carry 
needs to be considered. EDI is usually going to be only one of many ap- 
plications in an organization. 

a. Separating the functions 

The relationship between the EDI application and the trans-' 
port network should be considered case-by-case when deciding which EDI 
solution to adopt. The functions which the EDI application provide and 
the network needed to connect the application are conceptually inde- 
pendent. The EDI application is a processing problem— that of conver- 
sion, storage, collection, and auditing. The network is an infrastructure 
problem, the bearer of a wide variety of applications, economic wide area 
access, and where needed, routing, resilience, multiplexing, switching, and 
data stream and protocol conversion. 

b. Network management 

A good network management and maintenance operation is 
essential to sustain a high quality of service. This applies to any data 
network which is capable of providing the communications infrastructure 
for a company's internal and external networking needs. This is the area 
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which requires the most expense in skills. The cost of doing this often 
outweighs the capital investment of the equipment in the network. The 
EDI User should where possible take a advantage of third party service 
because the financial structure of the business may not afford the wide 
area network investment and running cost. The other significant issue in 
deciding whether a third party EDI service provider has the appropriate 
network solution for the company who wants to integrate external EDI 
within his company (the integrated-external scenario) is the extent of ge- 
ographic coverage provided by that third party service provider, 
c. Public and Private network 

One of the main determining factors when deciding between 
public and private networks is the cost. It is often actually cheaper to 
use a Public Data Network than for the company to build the network 
for itself. This is especially so when all related costs are included; that is 
to say, all equipments including network management tools, skilled staff 
resource, and all reased items such as private circuits. As an example, the 
comparison for a 22-site network spread nationally is shown in Figure 23 
[Ref. 5: p. 161]. Costs of using the Public Data Network comprise con- 
nection charge and quarterly rental for each data line (direct connection) 
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Figure 23. Full cost comparison of network implementation options 

from the customer's equipment. A list and a visual representation of the 
main Public Data Network services is shown in Figure 24 [Ref. 5: p. 163]. 

B. USE OF THIRD PARTY NETWORKS 

Third party networks are not used by all organizations that have im- 
plemented EDI. However, recent estimates place the percentage of or- 
ganizations that have implemented EDI and are currently using third 
party networks at approximately 60 percent of all EDI users. While it 
might seem logical that large organizations would be the least likely to 
use third party network services, approximately 75 percent of the Fortune 
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Figure 24, Public Data Network Senice 



500 companies who perform EDI use third party networks to some extent. 
Further, as the use of EDI continues to expand, the use of third party 
networks is also expected to expand. Most of the growth in EDI is likely 



to come from the implementation of EDI by small and middle-sized 
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companies as their larger trading partners begin to demand EDI trans- 
actions. Many of these companies do not believe that they have the in- 
house resources and skills necessary to establish direct EDI linkages with 
trading partners. Further, even in organizations where resources are 
available, many organizations have found that the use of a third party 
network relieves much of the systems development burden. 

There appear to be a number of key issues that require consideration 
by organizations considering the use of third-party Value Added Net- 
works or a third-party network in particular [Ref. 4: p. 77]. 

The first issue is whether to use a third-party network. The answer is 
primarily dependent on the firm's systems experience, transaction volumes 
(overall and between buyer and seller) and current and future states of 
your firm's computer hardware. With an experienced firm with signif- 
icant hardware, direct computer-to-computer links with selected key sup- 
pliers may be appropriate. For the largest multitude for firms, it appears 
that the use of a third-party network for EDI may be most appropriate. 
Once the decision to use a third-party network is made, then the decision 
criteria discussed can be applied. There are a few most significant issues 
that become critical when selecting a specific third party provider. First, 
it is important to determine that the provider has both the commitment 
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and financial resources to stay in business. It is essential that they provide 
continuity and continuous system enhancements. 

Secondly, it is imperative that the third party provider has the capa- 
bility of gateway to other third parties. It is important that the provider 
has two-way access to other third parties being used by the suppliers (and 
customers) to guarantee a smooth flow of data. Figure 25 [Ref. 4; p. 78] 
identifies a number of third-party Value Added Network providers and 
lists who they gateway with (as reported by the third-party networks 
themselves). 

Thirdly, it is important that the third-party be able to do business on 
a worldwide basis, if your firm is a global participant. The need to 
interface with foreign suppliers is an important, if not more so, than with 
domestic firms. 

Fourthly, your firm and the third-party should be active in furthering 
development and acceptance of inter-industry standards such as ANSI 
XI 2. Further development and refinement of these standards is extremely 
important to EDI and to fostering electronic communications. 

Finally, the third-party network should be working with other kinds 
of organizations such as financial institutions, trading companies, trans- 
portation firms and so forth. This will increase the likelihood of devel- 
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Figure 25. Selected third-party value added network gateways 

oping electronically integrated purchasing, man icturing, transportation 
and financial systems, the firm should then be able to benefit from any 
innovations. 
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VI. AUDI I ING AND SFXURITY ISSUES 



A. AUDITING 

In any EDI system, managers need to substantiate that the system is 
processing information correctly. This substantiation is provided by the 
capability to track any transaction to its closing. This physical tracking 
of a transaction through the system is called the audit trail. Since the 
audit trail is a primary source of information for purchasing profes- 
sionals, it is imperative that an adequate trail be available to them for 
verification purposes. In the EDI environment, the record of purchasing 
transactions between the buyer and suppiler is electronic rather than pa- 
per based. This change to electronic documentation impacts the manner 
in which the purchasing function controls the buying process. 

The degree to which the EDI system impacts the purchasing control 
process depends primarily on the level of sophistication of the EDI sys- 
tem. Physical documents such as manufacturing order releases, invoices, 
advance shipping notices, and bills of lading continue to exist and can 
be used as check mechanisms. As more vendors and document types are 
added to the EDI system, effective auditing and control procedures need 
to be designed into the system. With effective planning, controlling the 
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EDI system is relatively painless. Several elements are needed for the cost 

effective control of an EDI system. Those include: 

• Well defined and clearly written job procedures. 

• A systems user guide that parallels and complements the job proce- 
dures. 

• Systems technical documentatin. 

• A well-run data center. [Ref. 1 1: p. 23] 

The amount of time, effort, and resources placed on designing an ef- 
fective EDI control system depends upon the level of sophistication of the 
particular firm's EDI and automated purchasing system. The procure- 
ment manager must understand the auditing and control issues created 
by the use of an EDI system. The manager must have a knowledge of the 
function and use of these control mechanisms. The emphasis when de- 
signing procedures of the EDI system should be on the day-to-day control 
of the system. The control procedures must be good enough so that any 
kind of discrepancies that arise can be resolved and legal requirements 
satisfied. 

The EDI system must address the system concerns of auditing. It is 
important to involve auditing in the EDI planning and implementation 
process. Effective system auditing and storage procedures can only be ef- 
fectively built in early in the EDI system design and implementation 
processes. The type and nature of control mechanism should be deter- 
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mined jointly by purchasing and auditing. Many of these controls must 
be designed into the EDI system before the system is placed on-line. 
Adding control mechanisms after the system is in operation is costly and 
could affect the cost-effective functioning of the EDI system. 

Auditing, although an important issue, can be successfully managed. 
The issues and concerns can be systematically addressed. It is incumbent 
upon eveiy^ professional user of the EDI system to ensure that the system 
is performing as intended. Auditing issues must be addressed early in the 
EDI implementation. Auditors have been dealing with electronic data 
processing systems for years. They must utilize the knowledge of auditors 
in designing and implementing the EDI system controls. 

B. SECURITY 

The security of electronic data is a continuing managerial problem. 
Security issues for other internal computerized systems have many of the 
same characteristics as those associated with EDI systems. Security issues 
involving EDI should be viewed as an extension of current security issues, 
procedures, and standards which many organizations have already ad- 
dressed with other computerized systems [Ref. 4: p.4S]. 

The major difference between EDI and puchasing system security is 
that persons external to the organization are involved. Vital information 
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concerning pricing, contracts, quotes, and purchase orders are routinely 
transmitted electronically in the EDI environment. It is imperative that 
this information be secure and accessed by only authorized parties. 
Problems such as sending a purchase order to the wrong supplier must 
be avoided. Without proper monitoring and technological safeguards, 
information could accidentally or deliberately be made available to the 
wrong party. 

EDI security systems are required because information has value. The 
protection of the purchasing data base and maintaining the integrity of 
the data transmitted are the goals of the security system. Access re- 
strictions should be established by policy and enforced by written stand- 
ards and procedures. 

Protectiv^e security measures are built into each of three security ele- 
ments. First, Physical security measures restrict physical access to the 
system. Examples include locked doors, keys, guards, alarms, etc. Second, 
procedural security measures provide controls over authorization to see 
or use information. Examples include authorized employee lists, infor- 
mation elements access approval, passwords, and separation of duties. 
Third, logical security measures restrict access to information in electronic 
forms. Examples include software systems which implement access control 
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through the use of fingerprint recognition, voice recognition, and data 
transformation and encryption. In a technologically complex system, 
protection often requires a combination of all three security elements. 

Management should first subjectively and objectively look at the na- 
ture of the information involved in the EDI transfer. Security standards 
should directly reflect the value and sensitivity of the information. For 
information that is of high value to the organization, stringent security 
standards should be implemented. 

A well-designed security system ensures information availability to 
authorized user personnel, but at the same time protects the integrity of 
the data and the system. EDI security should be viewed as protection of 
the purchasing data base, the physical hardware, and the transmitted data. 
Security concerns occur through the entire EDI system, therefore EDI 
security must address both the external as well as internal environment. 
Identifying potential problem areas before the EDI system is put on-line 
will aid in the design of a fully protected system. Figure 26 [Ref. 4: p.50] 
presents tlie information flow from initial data base creation through in- 
formation dispersion to the supplier network. All nodes and links of this 
system should be carefully analyzed for security. 
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Figure 26. Threats from transaction of data from nodes 
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VII. COiN'CLUSION 



EDI is headed up in terms of volume of usage and is headed in in 
terms of integration with other management concepts and technnologies. 
Exponential growth is expected in EDI usage in the next few years. It is 
predicted that by 1993 over 70 percent of U.S. firms will be making sig- 
nificant use of EDI. By 1995, over 400,000 companies worldwide will be 
communicating electronically. The growth is expected to come from a 
number of directions. The United States is currently ahead of all other 
countries in terms of level of EDI use. However, other areas of the world 
are begining to catch up. Major EDI efforts are underway in Canada. 
Western Europe, the Pacific rim, and the Soviet Bloc, as well as in other 
parts of the world. One estimate places the annual grovvih rate of EDI 
worldwide at about 8S percent a year over the next three years [Ref. 12: 
p. 67-73]. 

EDI also going to expand out. New and different applications of EDI 
will be used. Currently, EDI is used for the communication of standard 
business documentation in a structured format. The communication is 
done using EDI standards and EDI networks. However, much of what 
is communicated in business does not fit that category. Electronic mail. 
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voice imaging, and videotext are currently being used to some degree for 
business communications. It is expected that EDI technology will even- 
tually expand to allow for the incorporation of such communications 
methods. EDI does not provide for the communication of drawings or 
graphics since these do not fit a standard structured format. However, the 
expansion of EDI to incorporate such items appears to be underway, as 
evidenced in CALS. At least one software supplier has announced that 
its EDI software can be used for the transmission of engineering drawing 
and graphics in CAD/CAM format. 

EDI has become an accepted and fairly standard method of commu- 
nication within the auto industry, more efforts are being undertaken to 
closely integrate EDI within internal systems, including JIT scheduling, 
information systems and Common Manufacturing Management Systems 
(CMMS). 

Legal considerations were seen as the major obstacle to implementing 
EDI. Terms and conditions which legally serve to bind and protect the 
buyer and seller would no longer accompany each purchase order under 
electronic transmission. Legal counsel can alleviate this obstacle by 
drafting blanket agreements covering all responsibilities and obligations 



72 



of the buyer and seller. This agreement needs to be signed by both parties 
prior to broad-scale EDI start-up [Ref. 13: p. 25]. 

Another concern involving EDI implementation is the security issues 
associated with transmission of business information through an external 
network. Information has value and must be protected. Internally infor- 
mation is protected via password or authorization codes. The safeguards 
that exist internally are also available for use in the networking environ- 
ment. Before selecting a vendor who provides networking services, a 
thorough evaluation of their security methods must be conducted. 

EDI will be essential to the procurement proce'^s making a key con- 
tribution to the firm's competitive advantage. EDI plays an important 
role in the pr icurement strategy of leading edge firms. Application of 
EDI will be increasing dramatically in the future on a worldwide basis. 
Extensive growth of EDI is on the near-term horizon. EDI is fast reaching 
the point where it will become a requirement to do business. Significant 
benefits, in the form of reduced costs, improved productivity, and better 
information, result from EDI. 
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